[E팀 김도훈] 백엔드 API 과제 제출 - #6
Conversation
upload
jinu0328
left a comment
jinu0328
left a comment
There was a problem hiding this comment.
과제 수행하시느라 수고 많으셨습니다! 몇가지 피드백을 남겨두었으니 참고해주시면 좋을 것 같습니다 😄
추가로 새로 스프링 프로젝트를 생성해주셨는지 깃허브에 업로드가 불필요한 build 관련 파일들이 업로드된 것 같습니다. 추후 프로젝트를 진행할때는 .gitignore를 통해 깃허브를 통해 관리될 필요 없는 파일, 디렉토리들은 깃 추적에서 제외시키면 좋을 것 같습니다 👍
| }) | ||
| @PostMapping // @Valid 추가 | ||
| public ResponseEntity<Map<String, String>> createTask(@Valid @RequestBody Task task) { | ||
| // Service 호출을 통해 작업 저장 |
There was a problem hiding this comment.
응답 DTO는 잘 활용하고 있지만, 요청 DTO를 별도로 두지 않고 엔티티 객체를 직접 사용하는 방식에 대해 몇 가지 단점이 있습니다.
ID와 같은 값이 클라이언트에 의해 설정될 위험이 있습니다. 클라이언트가 직접 값을 설정할 수 있기 때문에, 엔티티의 기본 키인 id 값이나 자동 생성되는 필드까지 포함될 수 있습니다.
Task의 구조가 변경되었을 때, 현재처럼 엔티티를 요청 body로 사용하면 controller와 service 레이어까지 모두 수정해야 합니다. 하지만 요청 DTO를 사용하면, 엔티티의 구조 변경 시 DTO와 service만 수정하면 되므로 controller에 미치는 영향을 최소화할 수 있습니다.
이러한 이유로 요청 DTO를 도입하면 향후 코드 변경과 유지보수 측면에서 더 유리할 수 있다는 점 참고해주시면 좋을 것 같습니다 😄
There was a problem hiding this comment.
API 응답의 ResponseEntity 구조가 거의 동일하게 반복되고 있습니다. status, message, data를 사용하는 구조를 반복적으로 작성하는 대신, 이를 하나의 공통 응답 객체로 관리하면 코드의 재사용성과 가독성을 크게 향상시킬 수 있을 것 같습니다. 현재 main 브랜치에도 그러한 방식으로 코드가 작성되어있으니 참고해주시면 좋을 것 같습니다! 👍
There was a problem hiding this comment.
RestControllerAdvice 어노테이션을 사용하여 전역 예외 처리 클래스를 구현하는 방식은 좋습니다! 👍
There was a problem hiding this comment.
Data 어노테이션과 Setter를 함께 사용하는 것은 불필요 할 수 있습니다. @DaTa는 @Getter, @Setter, @tostring, @EqualsAndHashCode, @requiredargsconstructor 등을 자동으로 생성해 주기 때문에, 별도로 @Setter를 사용하는 것이 중복될 수 있습니다.
추가로 어노테이션은 여러 코드를 자동으로 구성해주기에 편리하지만 때로는 필요하지 않은 메서드까지 자동으로 구현해주는 경우가 허다합니다. 각 어노테이션이 어디까지 자동으로 구현해주는지 한번 확인해보는 것도 좋은 공부가 될 것 같습니다 👍
2 participants
No description provided.